People with disabilities have had difficulty being integrated into the workforce. Such integration into the workforce is hampered by difficulties in working with computers. Consequently, accessibility aids have been developed to facilitate computer operation by disabled users. For example, a "screen reader utility" is a type of accessibility aid that reads information displayed on a video display to a visually impaired user, which enables the user to utilize the computer. These screen reader utilities operate by intercepting and analyzing information sent to the video driver. That is, when an application program wants to display information on the video display, it sends the information to a video driver, which is responsible for displaying the information on the video display. For example, when an application program wants to display a character, such as an ASCII character, the program sends an ASCII character code to the video driver indicating which character of the ASCII character set to display on the video display. The screen reader intercepts this ASCII character code, determines the phonetic sounds associated with the ASCII character, and audibly outputs the phonetic sounds to the visually impaired user, so that the visually impaired user can perceive the character written to the video display.
Although these screen reader utilities work well with text, screen reader utilities do not work well with graphical elements, such as the well-known graphical elements depicted in FIGS. 1A-1D. For example, FIG. 1A depicts a window with a menu bar, a title bar, a tool bar, a combo box, a header control, a tree view, a status bar, a list view, a size grip, and a scroll bar. FIG. 1B depicts a window with a progress bar, a check box-style button and status text. FIG. 1C depicts a window with an edit box and a push button-style button, and FIG. 1D depicts a window with a tab control, a list box, and a radio button-style button.
When a program wants to display a graphical element, like a button, on the video display, it sends a bitmap to the video driver containing the representation of the button. The screen reader intercepts this bitmap, and the screen reader then attempts to interpret the bitmap. To facilitate this interpretation, the screen reader maintains a database containing both the bitmaps representing the graphical elements utilized by a particular application program and an indication of what each bitmap represents. The screen reader compares the intercepted bitmap with the bitmaps in the database to determine the graphical element represented by the intercepted bitmap, and then the screen reader audibly indicates to the user what the graphical element is. In this manner, the screen reader audibly indicates to the user what information is displayed on the video display, including both text and graphical elements.
This method for analyzing a graphical element has a drawback: the screen reader utility must know in advance the exact bitmaps of the graphical elements utilized by a particular application program. Even the slightest variation between the bitmap sent to the video driver and the corresponding bitmaps in the database will prevent a match from being made, and the screen reader will be unable to identify the graphical element. In this case, the user receives an incomplete understanding of the information on the video display, thus reducing his or her effective use of the computer system. Hence, conventional screen readers must contain the bitmaps of the graphical elements utilized by a particular application program; conventional screen readers are thus application dependent. In other words, conventional screen readers cannot convey to a user information regarding graphical elements displayed by an application program without having a prior knowledge of the exact form of its graphical elements, and the screen reader will not work on another application program without having similar prior knowledge. As a result of these limitations, screen readers, and accessibility aids as a whole, are unreliable and do not convey sufficient information to a disabled user so that the user can understand all elements that are displayed on the video display, including both text and graphical elements. It is thus desirable to improve the way in which accessibility aids identify the elements displayed by an application program to help integrate disabled users into the work force.
Because the detailed description assumes knowledge of various well-known object-oriented techniques, an overview of such techniques is provided below. In some cases, this overview is specific to the C++ programming language.
Two common characteristics of object-oriented programming languages are support for data encapsulation and data type inheritance. Data encapsulation refers to associating functions with data, and inheritance refers to declaring a data type in terms of other data types. Thus, inheritance provides for a hierarchy of data types, where the data types defined lower in the hierarchy share the structure or behavior of the data types defined higher in the hierarchy.
In the C++ programming language, data encapsulation and inheritance are supported through the use of classes. A class is a defined type, and a class declaration describes the data members and function members of the class. The data members and function members of a class are bound together such that the function members operate on a particular instance of the data members of the class. An instance of a class is also known as an object of the class. A class thus provides a definition for a group of objects with similar properties and common behavior.
To allocate storage for an object of a particular type (class), an object is instantiated. The term "instantiating" refers to allocating memory for data members and associating the data members with the function members. Once instantiated, the function members of the particular object can be invoked to access and manipulate the data members. In this manner, the function members implement the behavior of the object, and the object provides a structure for encapsulating data and behavior into a single entity.
To support the concept of inheritance, classes may be derived from (based upon the declaration of) other classes. A derived class is a class that inherits the characteristics--data members and function members--of its base classes. A class that inherits the characteristics of another class is a derived class, and conversely, a class that does not inherit the characteristics of another class is a primary (root) class. A class whose characteristics are inherited by another class is a base class. A derived class may inherit the characteristics of several classes and have several base classes, which is known as multiple inheritance.
A class may also specify whether its function members are virtual. Declaring that a function member is virtual allows the function to be overridden by a function of the same name and type in a derived class. If a virtual function is declared without providing an implementation, then it is referred to as a pure virtual function. A pure virtual function is a virtual function declared with the pure specifier ("=0"). If a class specifies a pure virtual function, then any derived class needs to specify an implementation for that function member before an object of that class can be instantiated. A class which contains at least one pure virtual function member is an abstract class.
FIG. 2 is a block diagram illustrating typical data structures used to represent an object. An object comprises instance data (data members) and function members, which implement the behavior of the object. The data structures used to represent an object comprise instance data structure 201, virtual function table 202, and the function members 203, 204, 205. The instance data structure 201 contains a pointer to the virtual function table 202 and contains data members. The virtual function table 202 contains an entry for each virtual function member defined for the object. Each entry contains a reference to the code that implements the corresponding function member. In the following, an object will be described as an instance of a class as defined by the C++ programming language. One skilled in the art, however, will appreciate that other object models can be defined using other programming languages.
An advantage of using object-oriented techniques is, these techniques can be used to facilitate the sharing of objects. For example, a program implementing the function members of an instantiated object (a "server program") can share the object with another program (a "client program"). To allow an object of an arbitrary class to be shared with a client program, interfaces are defined through which an object can be accessed without the need for the client program to have access to the class implementation at compile time. An interface is a named set of logically related function members ("methods") and data members ("properties"). In C++, an interface is implemented as an abstract class with no data members and whose virtual functions are all pure. Thus, an interface provides a published protocol for two programs to communicate. Interfaces are typically used for derivation: a program defines (implements) classes that provide implementations for the interfaces the classes are derived from. Thereafter, objects are created as instances of these derived classes. Objects instantiated from a derived class implementing particular interfaces are said to "support" the interfaces. Typically, an object supports one or more interfaces depending upon the desired functionality.
The above-described object-oriented techniques have been successfully employed in Microsoft Corporation's Object Linking and Embedding (OLE) system. OLE is an object-based system in which each object conforms to the component object model by exposing a number of predefined interfaces. One of these interfaces is the IUnknown interface which contains the QueryInterface function member, and this function member provides access to all of the other interfaces supported by the object. Another interface supported by objects conforming to the component object model is the IDispatch interface, which allows the function members of an object to be invoked by a client without the client knowing at compile time the definition of the function member, which is known as dynamic binding. The IDispatch interface is described in greater detail in U.S. Pat. No. 5,515,536, entitled "Method and System for Invoking Methods of an Object Through a Dispatching Interface," issued May 7, 1996, which is hereby incorporated by reference. More generally, however, both OLE and the component object model are described in greater detail in Brockschmidt, Inside OLE, Second Edition, Microsoft Press (1995), at pages 1-143 and 635-730.